|
HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.〔(【引用サイトリンク】title=Using HTTP Compression (IIS 6.0) )〕 HTTP data is compressed before it is sent from the server: compliant browsers will announce what methods are supported to the server before downloading the correct format; browsers that do not support compliant compression method will download uncompressed data. The most common compression schemes include gzip and Deflate, however a full list of available schemes is maintained by the IANA.〔RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens."〕 Additionally, third parties develop new methods and include them in their products, for example the Google Shared Dictionary Compression for HTTP (SDCH) scheme implemented in the Google Chrome browser and used on Google servers. There are two different ways compression can be done in HTTP. At a lower level, a Transfer-Encoding header field may indicate the payload of a HTTP message is compressed. At a higher level, a Content-Encoding header field may indicate that a resource being transferred, cached, or otherwise referenced is compressed. Compression using Content-Encoding is more widely supported than Transfer-Encoding, and some browsers do not advertise for Transfer-Encoding compression to avoid triggering bugs in servers.〔('RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly' ), Chromium Issue 94730〕 ==Compression scheme negotiation== In most cases, excluding the SDCH, the negotiation is done in two steps, described in RFC 2616: 1. The web client advertises which compression schemes it supports by including a list of tokens in the HTTP request. For ''Content-Encoding'', the list in a field called ''Accept-Encoding''; for ''Transfer-Encoding'', the field is called ''TE''. GET /encrypted-area HTTP/1.1 Host: www.example.com Accept-Encoding: gzip, deflate 2. If the server supports one or more compression schemes, the outgoing data may be compressed by one or more methods supported by both parties. If this is the case, the server will add a ''Content-Encoding'' or ''Transfer-Encoding'' field in the HTTP response with the used schemes, separated by commas. HTTP/1.1 200 OK Date: mon, 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip The web server is by no means obliged to use any compression method – this depends on the internal settings of the web server and also may depend on the internal architecture of the website in question. In case of SDCH a dictionary negotiation is also required, which may involve additional steps, like downloading a proper dictionary from the external server. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「HTTP compression」の詳細全文を読む スポンサード リンク
|